IBIS Macromodel Task Group Meeting date: 1 April 2014 Members (asterisk for those attending): Agilent: * Fangyi Rao * Radek Biernacki Altera: David Banas ANSYS: * Dan Dvorscak Curtis Clark Cadence Design Systems: * Ambrish Varma Brad Brim * Kumar Keshavan Ken Willis Scott Huss Ericsson: Anders Ekholm Intel: * Michael Mirmak LSI * Amaresh Malipatil Dai Xingdong Maxim Integrated Products: Hassan Rafat Mentor Graphics: * John Angulo * Arpad Muranyi * Vladimir Dmitriev-Zdorov Andrey Matvienko Micron Technology: * Randy Wolff Justin Butterfield QLogic Corp. James Zhou Andy Joy SiSoft: * Walter Katz * Todd Westerhoff Mike LaBonte Teraspeed Consulting Group: Scott McMorrow Bob Ross The meeting was led by Arpad Muranyi. ------------------------------------------------------------------------ Opens: - Michael Mirmak asked for time to discuss an issue. - Arpad noted that Mike L. and Bob Ross sent emails that they could not attend. -------------------------- Call for patent disclosure: - None ------------- Review of ARs: - Arpad sent an email to prepare people for a vote on the direction of BIRD147 backchannel modeling. ------------- New Discussion: Amaresh introduced himself. He is in the SerDes architecture group at LSI. He is substituting for the usual LSI attendee. Michael has been looking with Bob at the ibischk6 parser. They found an issue with AMI parameters. Michael showed Tx_Rj on page 207. The Type is Float or UI. In Table 25 and 31, Float is not shown for Tx_Dj/Jitter/Rj/Sj. The parser is going off the tables, so which is correct? David said Float must be allowed. Todd said that Tx_Jitter has its own weird types like dual dirac. Michael clarified that this is a Format and not a Type. Todd said there is a purpose for Float or UI, as some parameters scale with data rate and some don't. Float can be independent of datarate. Michael concluded that therefore he should assume the tables are wrong and need to be fixed. He'll tell the parser developer to ignore the tables. Also, there is a document in the Version 6.0 directory of known issues. Arpad asked do we need a BIRD or is it an editorial issue. Michael thought a BIRD is needed to bring greater attention to it. Radek suggested checking the original BIRD text. BIRD 147: Arpad noted that we discussed last week taking an informal vote. An email was sent out last week to get attention and ended up bringing up discussion on what the questions really are. Ambrish also contacted Arpad to let him know that he added a statistical flow to a new draft of BIRD147. Should we look at the BIRD or do the vote? Walter said he would like to move for a straw man vote on the questions posted in his email, since there are subtleties to discuss. Ambrish said he still believes statistical flow is not representative of the deveice, but he hears there is a demand for it in the industry. So, he decided to add the support for it in the BIRD. Michael seconded the motion. Walter described the vote. A vote of Yes means that you desire to have a single BIRD that: 1. Enhances IBIS AMI to enable Backchannel/Training/Co-Optimization. 2. It will not be required that an IBIS 7.0 AMI model support optimization. 3. Optimization can be performed in either statistical (Init) and/or time domain (GetWave). a. It will not be required that an AMI model be able to support both statistical and time domain optimization. b. An AMI model may be able to support both statistical and time domain optimization. 4. Enables an EDA tool to analyze the performance of the optimized channel. 5. Communicates to the EDA tool the Tx and Rx setting for the optimized channel. Vladimir asked for clarification on what Yes/No votes mean. Walter responded that yes means any BIRD must satisfy the conditions stated. Walter stressed the importance of item 5. Michael asked if item 5 means the EDA tool or the user. Walter clarified that it means that it communicates to the user. Kumar disagreed with the need for communicating settings, especially from the Rx. David said we need to look at slides 4,5,6 of Walter's presentation to understand what the requirements really are that we are voting on. Michael thinks we are voting on the sense of the committee about requirements, not setting anything in stone. Walter responded that item 5 is significant. BIRD147 does analyze the performance of the optimized channel, but there is a need to get the particular Tx tap coefficients from the model. Current BIRD147 in the time domain doesn't give a mechanism for doing this. Kumar noted that there are too many types of Tx that report their settings in different ways to standardize the output. Walter responded that there are always going to be tap values that get set or emphasis values that get set. Kumar said that Cadence should get a chance to present their flow and then see what is not covered. Ambrish added that the Tx and Rx can communicate about what values need to be changed in their flow. Todd said to Walter that he was hearing a lot of confusion about what the votes mean. Todd recommended withdrawing the motion, giving time to hear Cadence's BIRD and discuss next week. Walter said he would like to get Cadence's BIRD changes to look at off line. Ambrish said we can start discussion now and look at changes off line. David said he would like to see Walter's presentation first. Arpad noted a comment from Bob that whatever we do, we should solidify where we are at with BIRD147, posting a BIRD147.2, then moving on with discusion. It would be a good fall back point if we mess it up later. David asked what we need more than the copy in the work archive. Walter noted he thought this discussion was academic and we should move on. Walter withdrew his motion. Walter showed his presentation "Tx_Init_Optimizes". It is related to the redriver BIRD, but also to backchannel. Tx_Init_Optimizes is a proposed name for a new parameter. The presentation is on why Tx optimizing is wrong and how to fix it. Walter stated that the redriver statistical flow in IBIS 6.0 is incorrect. A Tx optimizing itself is wrong because no silicon does this. Kumar felt that included settings such as P7 for PCI express are a useful place to start. Todd added that what we see are Tx models that look at impulse reponse and try to optimize to the channel assuming there is no Rx equalization. We see that Tx taps can be dialed back and let the Rx optimize better. David responded that we shouldn't embed language in a BIRD that could be anti-innovation. Walter resopnded that AMI files should advertise if the Tx is doing this or not. David said imagine a Tx that has three settings: manual, auto or training. Adding this parameter assumes auto has no place in the AMI universe. Michael stated that we need to know if a tool is handling optimization. Walter stated that (Usage In) (List False) is manual, the True setting is Auto, and training he thinks is the same as a False setting. Ambrish thinks there is nothing stopping this from happening with Model_Specific parameters. Ambrish asked for time to talk over the BIRD147 changes since Walter's presentation was more about the redriver flow and not backchannel modeling. Ambrish noted one BIRD change was to use AMI_parameters_out for passing a string from the Tx AMI_Init function to the Rx AMI model. Section 1.5.2 was added for AMI_Init statistical flow. Tx AMI_Init is called twice in the flow. Walter noted that the flow doesn't work if the Rx increments registers, only if it sends back actual tap coefficients. Walter requested time next Tuesday to give another prsentation on Tx models that allows more flexiblity in the backchannel process. Arpad requested Walter and Ambrish to send their documents to Mike LaBonte for posting. ------------- Next meeting: 08 April 2014 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives